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APPEAL BRIEF 

Mail Stop Appeal Brief - Patents 
Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 

Sir: 

Appellants submit this appeal brief in the above-referenced application. A notice of 
appeal was filed on October 31, 2008. A pre-appeal brief request for review was also filed on 
October 31, 2008. A Notice of Panel Decision from Pre-Appeal Brief Review, mailed November 
26, 2008, held that the application remains under appeal. 



REAL PARTY IN INTEREST 

SAP Aktiengesellschaft (SAP) of Walldorf, Germany, is the real party in interest for all 
issues related to this application. SAP owns this patent application by assignment. 

RELATED APPEALS OR INTERFERENCES 

There are no other prior or pending appeals, interferences or judicial proceedings known 
by the undersigned, or believed by the undersigned to be known to Appellant or the assignee, 
SAP, 'which may be related to, directly affect or be directly affected by or have a bearing on the 
Board's decision in the pending appeal.' 

STATUS OF CLAIMS 

This application contains claims 1-27, all of which stand rejected. 
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A. Claims 1-10, 13-18, 20, and 22-27 were rejected under 35 U.S.C. § 103(a) as 
unpatentable over U.S. Pat. Pub. No. 2002/0120538 to Carrie et al. ("' Carrie d, in view of U.S. 
Patent App. Pub. No. 2005/0192826 f Kanefskv "). 

B. Claims 11, 19 and 21 were rejected under 35 U.S.C. § 103(a) as unpatentable over 
Corrie in view of Kanefsky , and in further view of Official Notice. 

C. Claim 12 was rejected under 35 U.S.C. § 103(a) as unpatentable over Corrie and 
Kanefskv. and in further view of U.S. Patent No. 7,111,010 to Chen et al. ("Chen"). 

All rejections are appealed in this brief. 

STATUS OF AMENDMENTS 

Responsive to a Final Office Action mailed August 1, 2008, Applicants submitted a 
Response to the Final Office Action under 37 C.F.R. § 1.116 on September 30, 2008, which 
contains no amendment to claims. 

It is understood for purposes of the appeal that any Amendments to date have already 
been entered by the Examiner. 

SUMMARY OF CLAIMED SUBJECT MATTER 

The subject matter of the current pending claims relates to a method and system for 
managing for a recipient a plurality of grants received from a plurality of grant sponsors, (see, 
e.g., the Specification, pages 1-3, paragraphs 1, 2, 5, and 11). 

The present invention might best be understood in view of the following example. 
Consider a recipient organization, e.g., a university, that receives grants or funding from 
multiple grantors, e.g., federal government agencies, state agencies, industrial companies, and 
foundations. For each grant, a grantor may impose certain requirements and limitations that 
specify how the grant may be expended. On the other hand, the daily expenditures during the 
course of operation at the university may be run on a transaction system, e.g., an enterprise 
management system. Upon receiving an expenditure request from, e.g., a professor, the 
transaction system may need to select a grant based on requirements and limitations from the 
multiple grants available to the university to fulfill the expenditure request. The present 
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invention is directed to a grant management system that is capable of managing expenditure 
transactions of a grantee organization in accordance with requirements of multiple grants 
awarded to the grantee. 

Claim 1 

The presently pending independent claim 1 is directed to a computer-implemented 
grants management method for managing a plurality of grants for a recipient received from a 
plurality of grant sponsors, (see, e.g., the Specification, pages 1-4, paragraphs 1, 2, 5, 11, and 
15). The method recites responsive to a transaction request and data associated therewith, 
converting values of the associated data from a domain of a transaction system to a domain 
defined for one of the plurality of grants, (see, e.g., the Specification, page 5, paragraph 16, 
page 6, paragraph 22, and FIGS. 1 and 3)f The interpretation logic 170 may convert 
transaction data from a domain of the transaction processing system 130 to a domain of a 
grant. In the foregoing examples, while the university's transaction processing system 130 may 
use U.S. dollars for currency values, to determine whether a transaction can be admitted under 
Sponsor A's grant, the interpretation logic 170 may convert financial values to Euros"). 

The method of claim 1 further recites determining if the converted data maps to a 
classification that has been defined under the one of the plurality of grants to be valid, (see, 
e.g., the Specification, page 5, paragraph 17 and page 7, paragraph 24). If so, the method 
recites determining, based on a set of rules derived from administrative and financial 
requirements of the plurality of grants and encoded in a database, if the converted data causes 
a limit defined under the one of the plurality of grants to be exceeded, (see, e.g., the 
Specification, page 2, paragraph 11, page 5, paragraph 18, and page 7, paragraph 25). In the 
case that the limit is not exceeded, the method provides admitting the requested transaction; 
otherwise, the method recites rejecting the requested transaction, (see, e.g., the Specification, 
page 5, paragraphs 17 and 18, page 7, paragraphs, 23 and 24, and FIGS. 1 and 3)(" The AVC 
manager 190 may cause a transaction to be rejected, even if the transaction maps to a valid 
category under the grant, if the transaction would cause a limit defined for the grant to be 
exceeded."). 
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Claim 6 

The presently pending independent claim 6 is directed to an enterprise management 
system_for managing a plurality of grants for a recipient received from a plurality of grant 
sponsors, (see, e.g., the Specification, pages 1-4, paragraphs 1, 2, 5, 11, and 15). The system 
of claim 6 includes a transaction management system, operating under a predetermined set of 
transaction rules and responsive to a transaction request by validating and accepting the 
transaction, (see, e.g., the Specification, page 3, paragraph 13, and FIG. 1, 130)(" The 
transaction processing system 130 may include a transaction logic 140, and a transaction 
database 150. The transaction logic 140 may receive transaction requests from operators at 
various terminals (e.g., 110) and process the transaction request according to transaction 
rules."). 

The system of claim 6 further recites a grants management system provided in 
communication with the transaction system, (see, e.g., the Specification, page 3, paragraph 14, 
and FIG. 1). The grant management system of claim 6 further includes an interpretation logic 
unit to convert values of the transaction request from a domain of the transaction system to a 
domain defined for grant identified from the plurality of grants, (see, e.g., the Specification, 
page 5, paragraph 16, and FIG. 1, 170), a dimensional control unit to determine if the 
converted data maps to a classification that has been defined under the grant to be valid, (see, 
e.g., the Specification, page 5, paragraph 17, and FIG. 1, 180), an availability control unit to 
determine, based on a set of rules derived from administrative and financial requirements of the 
plurality of grants and encoded in a database, if the converted data would cause a limit defined 
under the grant to be exceeded, (see, e.g., the Specification, page 5, paragraph 18, and FIG. 1, 
190), and a database storing converted transaction of the transaction requests that map to 
valid classifications that do not exceed the defined limits, (see, e.g., the Specification, pages 5- 
6, paragraphs 18-20, and FIGS. 1 and 2). 

Claim 10 

The presently pending independent claim 10 relates to an enterprise management 
system for managing a plurality of grants for a recipient received from a plurality of grant 
sponsors, (see, e.g., the Specification, pages 1-3, paragraphs 1, 2, 5, and 11). The system of 
claim 10 includes a transaction management system, operating under a predetermined set of 
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transaction rules and responsive to a transaction request by validating and accepting the 
transaction, (see, e.g., the Specification, page 3, paragraph 13, and FIG. 1, 130)(" The 
transaction processing system 130 may include a transaction logic 140, and a transaction 
database 150. The transaction logic 140 may receive transaction requests from operators at 
various terminals (e.g., 110) and process the transaction request according to transaction 
rules."). 

The system of claim 10 further includes a grants management system provided in 
communication with the transaction system, (see, e.g., the Specification, page 3, paragraph 14, 
and FIG. 1). The grants management system is, responsive to the transaction request, further 
configured for (1) converting values of the transaction request from a domain of the transaction 
system to a domain defined for grantjdentified from the plurality of grants, (see, e.g., the 
Specification, page 5, paragraph 16, page 6, paragraph 22, and FIGS. 1 and 3), (2) determining 
if the converted data maps to a classification that has been defined under the grant to be valid, 
(see, e.g., Id.), (3) if so, determining, based on a set of rules derived from administrative and 
financial requirements of the plurality of grants and encoded in a database, if the converted 
data causes a limit defined under the grant to be exceeded, and (4) causing the transaction 
management system to reject to requested transaction if the limit is exceeded, (see, e.g., the 
Specification, page 5, paragraphs 17 and 18, page 7, paragraphs, 23 and 24, and FIGS. 1 and 
3)(" The AVC manager 190 may cause a transaction to be rejected, even if the transaction 
maps to a valid category under the grant, if the transaction would cause a limit defined for the 
grant to be exceeded."). 

Claim 13 

The presently pending independent claim 13 relates to a computer-implemented grants 
management method for managing a plurality of grants for a recipient received from a plurality 
of grant sponsors, (see, e.g., the Specification, pages 1-3, paragraphs 1, 2, 5, and 11). The 
method of claim 13 recites receiving a transaction request and data associated with the 
transaction request from a transaction management system of a grant recipient, (see, e.g., the 
Specification, page 5, paragraph 16, page 6, paragraph 22, and FIGS. 1 and 3). The method of 
claim 13 further recites determining, based on a set of rules derived from administrative and 
financial requirements of the plurality of grants and encoded in a database, if the transaction 
request satisfies the rules imposed by the sponsor, (see, e.g., the Specification, page 5, 
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paragraph 16, page 6, paragraph 22, and FIGS. 1 and 3). If so, the method recites admitting 
the transaction request; otherwise, rejecting the transaction request, (see, e.g., the 
Specification, page 5, paragraphs 17 and 18, page 7, paragraphs, 23 and 24, and FIGS. 1 and 
3). 

Claim 20 

The presently pending independent claim 20 relates to a computer-implemented 
reporting and billing management method for managing a plurality of grants for a grantee 
received from a plurality of grant sponsors, {see, e.g., the Specification, page 9, paragraph 30, 
and FIG. 1). The method of claim 20 recites determining on a grants management system of 
the grantee if a report and/or a bill are due according to a predetermined set of reporting and 
billing rules imposed by a sponsor of a grant on the grantee, (see, e.g., Id.)(" the GM system 
also may provide for a flexible billing/reporting tool to satisfy various sponsor requirements."). 
The method of claim 20 further recites retrieving transactional data stored in the sponsor's 
terms from a transaction management system of the grantee, (see e.g., the Specification, page 
9, paragraph 31). The method of claim 20 still further recites if the report and/or the bill are 
determined to be due, generating the report and/or the bill in the sponsor's terms, (see e.g., 
the Specification, page 9, paragraph 32)(" some grants may specify that reporting and/or billing 
is to be performed only after certain milestones are achieved pursuant to a grant."). 

Claim 23 

The presently pending independent claim 23 relates to an enterprise management 
system for managing a plurality of grants for a grantee received from a plurality of grant 
sponsors, (see, e.g., the Specification, pages 1-3, paragraphs 1, 2, 5, and 11). The system of 
claim 23 recites a transaction management system, operating under a predetermined set of 
transaction rules imposed by a sponsor on the grantee and responsive to a transaction request 
by validating and accepting the transaction, (see, e.g., the Specification, page 9, paragraph 30, 
and FIG. 1, 130). The system of claim 23 further recites a grants management system of the 
grantee provided in communication with the transaction system, to determine if the transaction 
request satisfies the predetermined set of transaction rules imposed by the sponsor, and if so, 
storing transaction data, (see, e.g., the Specification, page 9, paragraph 30, and FIG. 1, 160), 
where the grants management system includes a reporting and billing manager to generate a 
report and/or a bill to the sponsor pursuant to a predetermined set of reporting and billing rules 
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and the transaction data, (see, e.g., the Specification, page 9, paragraphs 30 and 31, and FIG. 
1). 

Claim 27 

The presently pending independent claim 27 relates to an enterprise management 
system for managing grants for a grantee received from grant sponsors, (see, e.g., the 
Specification, pages 1-3, paragraphs 1, 2, 5, and 11). The system of claim 27 includes a 
transaction management system operating under a predetermined set of transaction rules and 
responsive to a transaction request by validating and accepting the transaction, (see, e.g., the 
Specification, page 3, paragraph 13, and FIG. 1, 130). 

The system of claim 27 further includes a grants management system provided in 
communication with a transaction system, (see, e.g., the Specification, page 3, paragraph 14, 
and FIG. 1). The grant management system of claim 27 further includes an interpretation logic 
unit to convert values of the transaction request from a domain of the transaction system to a 
domain defined for an identified grant, (see, e.g., the Specification, page 5, paragraph 16, and 
FIG. 1, 170), a dimensional control unit to determine if the converted data maps to a 
classification that has been defined under the grant to be valid, (see, e.g., the Specification, 
page 5, paragraph 17, and FIG. 1, 180), an availability control unit to determine, based on the 
predetermined set of transaction rules, if the converted data would cause a limit defined under 
the grant to be exceeded, (see, e.g., the Specification, page 5, paragraph 18, and FIG. 1, 190), 
a database storing converted transaction of the transaction requests that map to valid 
classifications that do not exceed the defined limits, (see, e.g., the Specification, pages 5-6, 
paragraphs 18-20, and FIGS. 1 and 2), and a reporting and billing manager to submit a report 
and/or a bill according to a predetermined set of rules, (see, e.g., the Specification, page 9, 
paragraphs 30 and 31, and FIG. 1). 

GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Whether claims 1-10, 13-18, 20, and 22-27, which stand rejected under 35 U.S.C. § 
103(a), are unpatentable, over U.S. Pat. Pub. No. 2002/0120538 to Carrie et al. f Carrie "! in 
view of U.S. Patent Application Publication No. 2005/0192826 f' Kanefskv 'l 
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Whether claims 11, 19, and 21, which stand rejected under 35 U.S.C. § 103(a), are 
unpatentable over Corrie , in view of Kanefsky. and in further view of Official Notice. 

Whether claim 12, which stands rejected under 35 U.S.C. § 103(a), is unpatentable over 
Corrie , in view of Kanefsky, and in further view of U.S. Patent No. 7,111,010 to Chen et al. 
("Chen"). 

ARGUMENT 

A. The Rejections of Claims 1-10, 13-18, 20, and 22-27 under 35 U.S.C. 
103(a) Must Be Reversed 

To reject a claim under 35 U.S.C. § 103(a), the Office bears the initial burden of 
presenting a prima facie case of obviousness. In re Rijckaert, 9 F.3d 1531, 1532, 28 U.S.P.Q.2d 
1955, 1956 (Fed. Cir. 1993). To establish prima facie obviousness, several criteria must be 
satisfied. First, there must be some suggestion or motivation to modify or combine reference 
teachings. In re Fine, 837 F.2d 1071, 5 U.S.P.Q.2d 1596 (Fed. Cir. 1988). This teaching or 
suggestion to make the claimed combination must be found in the prior art and not based on 
the application disclosure. In re Vaeck, 947 F.2d 488, 20 U.S.P.Q.2d 1438 (Fed. Cir. 1991). As 
clearly indicated by the Supreme Court, it is "important to identify a reason that would have 
prompted a person of ordinary skill in the relevant field to combine the [prior art] elements" in 
the manner claimed. See KSR Int'l Co. v. Teleflex, Inc., 127 S. Ct. 1727 (2007). In this 
regard, the Supreme Court further noted that "rejections on obviousness cannot be sustained 
by mere conclusory statements; instead, there must be some articulated reasoning with some 
rational underpinning to support the legal conclusion of obviousness." Id., at 1396. Second, 
there must be a reasonable expectation of success. In re Merck & Co., Inc., 800 F.2d 1091, 
231 U.S.P.Q. 375 (Fed. Cir. 1986). Third, the prior art reference(s) must teach or suggest all of 
the claim features. In re Royka, 490 F.2d 981, 180 U.S.P.Q. 580 (C.C.P.A. 1974). 

Of course, an Examiner's rejections cannot stand if the art relied upon is not prior art at 
all. The 35 U.S.C. 102(e) critical reference date of a U.S. application publication is entitled to 
the benefit of the filing date of a provisional application only if the provisional application 
properly supports the subject matter relied upon to make the rejection in compliance with 35 
U.S.C. 112, first paragraph. M.P.E.P. 2136.03 III. 
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1. The Kanefsky Reference Is Not a Proper Prior Reference 

Claims 1-10, 13-18, 20, and 22-27 were rejected under 35 U.S.C. § 103(a) as 
unpatentable over Carrie , in view of Kanefsky, U.S. Patent Application Publication No. 
2005/0192826, filed August 20, 2004 ("the Kanefsky 2004 filing"). However, the combination 
of Carrie and the Kanefsky 2004 filing does not render claims 1-10, 13-18, 20, and 22-27 
unpatentable under 35 U.S.C. § 103(a) because the Kanefsky 2004 filing is not prior art under 
35 U.S.C. § 103(a)/102(e). 

The the Kanefsky 2004 filing is a published application that was filed after the present 
application's filing date. In the Final Office Action, the Examiner asserted the Kanefsky 2004 
filing benefits from the effective filing date of its provisional application, which was filed on 
August 21, 2003 (" Kanefsky's Provisional "). Kanefsky's Provisional , however, does not disclose 
the same subject matter as the Kanefsky 2004 filing . In particular, it does not disclose the 
same subject matter from the Kanefsky 2004 filing on which the Examiner's rejection are based. 
Accordingly, the relied on portions of the Kanefsky 2004 filing do not benefit from the priority of 
Kanefsky's Provisional and are not prior art against the pending claim. 



Table 1 below shows a timeline of relevant filing dates: 



DOCUMENTS 


DATES 


Kanefsky's Provisional filing date: 


August 21, 2003 


The Present Application filing date: 


September 30, 2003 


Kanefsky, U.S. Publ'n. 2005/0192826 filing date: 


August 20, 2004 



Table 1. 



As explained below, Kanefsky's Provisional does not provide § 112, first paragraph support for 
the subject matter relied upon from the Kanefsky 2004 filing and, therefore, the Kanefsky 2004 
filing is not prior art to the pending claims of the present application. 

Consider claim 1, for example. In his rejection, the Examiner admits that the primary 
reference, Carrie, does not disclose the feature of a computer-implemented grants management 
method for managing a plurality of grants for a recipient received from a plurality of grant 
sponsors or grantors. The Examiner asserted that the Kanefsky 2004 filing discloses this 
subject matter at Fig. 1 and in the text at H 21. However, Kanefsky's Provisional does not 
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provide this disclosure at all. For example, Kanefsky's Provisional does not include any 
figure that matches the Fig. 1 or any text that matches H 21 of the Kanefsky 2004 filing . 



Indeed, any reading of Kanefsky's Provisional does not support the relied on subject 
matter allegedly contained in the Kanefsky 2004 filing . The Kanefsky's Provisional is merely 
concerned with a grant reporting system for a Grantor. For example, in its background section, 
Kanefsky's Provisional makes clear it intends to address the problem of how each of Federal 
Grantor organizations handles the reporting task for the Grantor. However, it doe not disclose 
a grant management system for a recipient (Grantee) to manage the expenditure of grants 
from multiple Grantors. 

Furthermore, in his rejection, the Examiner admits that Carrie does not disclose the 
feature of determining if the converted data maps to a domain defined for one of the plurality 
of grants to be valid recited in claim 1. The Examiner asserted the text in \ 33 of the Kanefsky 
2004 filing as allegedly disclosing the feature. However, Kanefsky's Provisional does not 
provide this disclosure at all. The text in H 33 of the Kanefsky 2004 filing is merely 
concerned with a description of the corresponding Fig. 4 therein. However, any reading of 
Kanefsky's Provisional does not contain a matching Fig. 4 or describe a system as illustrated in 
Fig. 4 of the Kanefsky 2004 filing . Therefore, the subject matter relied upon by the Examiner 
as allegedly contained in H 33 of the Kanefsky 2004 filing is totally unsupported by Kanefsky's 
Provisional . 

Applicants in a Response to the Final Office Action filed on September 30, 2008 and 
again in a Pre-Appeal Brief Request for Review filed on October 31, 2008 particularly pointed 
out the improper use of the Kanefsky 2004 filing as prior art under § 103(a)/102(e) as applied 
to the claims, specifically claim 1, of the present application. However, the Examiner failed to 
provide any explanation as to how the Kanefsky's Provisional may provide any factual support 
for the subject matter relied on from the Kanefsky 2004 filing . The Examiner failed the burden 
of presenting a prima facie case of obviousness. 

The Examiner, in the Advisory Action, asserted M.P.E.P. 706 as the legal base and stated 
that "if a reference properly claims benefit under 35 U.S.C. 119(e) to a provisional application, 
the effective filing date is the filing date of the provisional application for any claims which fully 
supported under the first paragraph of 35 U.S.C. 112 by the provisional application." The 
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Examiner misunderstood and misapplied M.P.E.P. 706. M.P.E.P. 706 is directed to situations 
where a patent or patent application claims priority from its provisional application for the 
purpose to gain priority against prior art. However, where the Examiner tried to rely on the 
filing date of a provisional application of a patent or patent application to gain prior art status in 
rejecting pending claims such as in this case, the Examiner must show that the subject matter 
relied on in rejecting the pending claims is indeed supported by the provisional application as 
required under M.P.E.P. 2136.03 III. In the present case, there is simply no such support from 
Kanefsky's Provisional . 

Accordingly, Kanefsky is not a proper reference to claim 1 or any of its dependent claims 

2-5. 

Similarly, the Examiner asserted Fig. 1 and the text in ^ 22 and 33 of the Kanefsky 
2004 filing in rejecting independent claims 6, 10, 20, and 27, and relied on Fig. 1 and the text 
in H 22 of the Kanefsky 2004 filing in rejecting independent claims 13 and 23. Therefore, for 
the same reasons discussed above, Kanefsky is not a proper reference to claims 6, 10, 13, 20, 
23, and 27 or any of their respective dependent claims 7-9, 14-18, 22, and 24-26. 

Therefore, reversal of rejections to claims 1-10, 13-18, 20, and 22-27 is respectfully 
requested. 

2. The Combination of Carrie and Kanefsky's Provisional Does Not Render 
Claims 1-10, 13-18, 20, and 22-27 Unpatentable 

As discussed above, the Examiner did not explain how Kanefsky's Provisional supports 
the subject matter relied on from the the Kanefsky 2004 filing . Therefore, the Examiner failed 
the burden of presenting a prima facie case of obviousness. 

Furthermore, any reading of Carrie in view of Kanefsky's Provisional does not render 
claims 1-10, 13-18, 20, and 22-27 unpatentable. 

As discussed above, independent claim 1 states in part: 

a computer-implemented grants management method for managing a plurality of 
grants for a recipient received from a plurality of grant sponsors. 
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The Examiner admits that the primary reference, Carrie , does not disclose this feature. The 
Kanefsky's Provisional does not disclose this feature either. The Kanefsky's Provisional is merely 
concerned with a grant reporting system for a Grantor. For example, in its background section, 
Kanefsky's Provisional makes clear it intends to address the problem of how each of Federal 
Grantor organizations handles the reporting task. It doe not disclose a grant management 
system for a recipient (Grantee) to manage expenditures of grants from multiple Grantors. 

Further, independent claim 1 states in part: 

responsive to a transaction request and data associated therewith, converting 
values of the associated data from a domain of a transaction system to a domain 
defined for one of the plurality of grants. 

The Examiner admits that the primary reference, Carrie , does not disclose this feature. The 
Kanefsky's Provisional does not disclose this feature either. In particular, it does not disclose "a 
domain of a transaction system," "a domain defined for one of the plurality of grants" and 
converting values from the transaction system domain to grants domain. Therefore, the 
combination of Carrie and the Kanefsky's Provisional does not render claim 1 and its dependent 
claims 2-5 unpatentable. Accordingly, claims 1-5 are allowable. 

Independent claims 6, 10, 13, 20, 23, and 27 and their respective dependent claims 7-9, 
14-18, 22, and 24-2 includes features substantially similar to claim 1 and therefore, are 
allowable for the same reasons as claim 1. 

3. The Final Office Action Did Not Consider All Elements in Claims 1-5 

M.P.E.P. 2143.03 makes it clear that the Examiner must consider all elements in a claim 
in examination. The Examiner failed to consider all elements of the pending claims 1-5 in the 
final rejection. Independent claim 1 in particular recites: 

responsive to a transaction request and data associated therewith, converting 
values of the associated data from a domain of a transaction system to a domain 
defined for one of the plurality of grants. 

In the Final Office Action, the Examiner first admits that the primary reference, Carrie , does not 

disclose the feature. However, the Examiner failed to discuss or point out any part of the 

secondary reference, Kanefsky , corresponds to this feature in the subsequent rejection, (see 

Final Office Action, pages 5-6). Applicants in the Response to Final Office Action and again in 
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Pre-Appeal Brief Request for Review particularly pointed out the Examiner's failure to consider 
the above-identified element. However, the Examiner ignored Applicant's requests for 
consideration of the element. Therefore, for these additional reasons, reversal of the rejections 
to claim 1 and its dependent claims 2-4 is respectfully requested. 

B. The Rejection of Claims 11, 19, and 21 under 35 U.S.C. 103(a) Must Be 
Reversed 

Claims 11, 19, and 21 depend from independent claims 10, 13, and 20, respectively and 
therefore, are allowable for the same reasons as claims 10, 13, and 20 since the alleged Official 
Notice does not cure or allege to cure the critical deficiencies of the combination of Carrie and 
Kanefsky . 

Therefore, reversal of rejections to claims 11, 19, and 21 is respectfully requested. 

C. The Rejection of Claims 12 under 35 U.S.C. 103(8) Must Be Reversed 

Claim 12 depends from independent claim 10 and therefore, is allowable for the same 
reasons as claim 10 since the alleged tertiary Chen reference does not cure or allege to cure the 
critical deficiencies of the combination of Carrie and Kanefsky . 

Therefore, reversal of rejection to claim 12 is respectfully requested. 

CLAIMS APPENDIX 

A "Claims Appendix" is attached hereto and appears on the page labeled "Claims 
Appendix." 

EVIDENCE APPENDIX 

No evidence has been submitted pursuant to 37 C.F.R. §§ 1.130, 1.131 or 1.132. No 
other evidence has been entered by the Examiner or relied upon by Appellant in the appeal. An 
"Evidence Appendix" is attached hereto. 

RELATED PROCEEDINGS APPENDIX 

As indicated above, there are no other appeals or interferences related to this 
application. As such, there are no "decisions rendered by a court or the Board in any 



NY01 1641577 



- 13- 



proceeding identified pursuant to [37 C.F.R. § 41.37(c)(l)(ii)]" to be submitted. A "Related 
Proceedings Appendix" is nevertheless attached hereto. 



CONCLUSION 

Applicants respectfully request reversal of the obviousness rejection to claims 1-27. 



Respectfully submitted, 



Date: December 29, 2008 /Robert L Hails/ 

Robert L. Hails 
Registration No. 39,702 



KENYON & KENYON 
1500 K Street, N.W. 
Washington, D.C. 20005 
Ph.: (202) 220-4200 
Fax.: (202) 220-4201 
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CLAIMS APPENDIX 

1. A computer-implemented grants management method for managing a plurality of grants 
for a recipient received from a plurality of grant sponsors, comprising: 

responsive to a transaction request and data associated therewith, converting values of 
the associated data from a domain of a transaction system to a domain defined for one of the 
plurality of grants, 

determining if the converted data maps to a classification that has been defined under 
the one of the plurality of grants to be valid, 

if so, determining, based on a set of rules derived from administrative and financial 
requirements of the plurality of grants and encoded in a database, if the converted data causes 
a limit defined under the one of the plurality of grants to be exceeded, and 

if not, admitting the requested transaction, 

otherwise, rejecting the requested transaction. 

2. The method of claim 1, wherein the domain of the transaction system and the domain 
of one of the plurality of grants are different. 

3. The method of claim 1, wherein the domain of the transaction system is the same as the 
domain of the one of the plurality of grants. 

4. The method of claim 1, further comprising storing the transaction data in a database in 
the domain defined for the one of the plurality of grants. 

5. The method of claim 1, further comprising: 

determining if a report and/or a bill are due according to a predetermined set of 
reporting and billing rules; 

retrieving transactional data stored in the domain defined for the one of the plurality of 
grants; and 

if the report and/or the bill are determined to be due, generating the report and/or the 
bill in the domain defined for the one of the plurality of grants. 
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6. An enterprise management system for managing a plurality of grants for a recipient 
received from a plurality of grant sponsors, comprising: 

a transaction management system, operating under a predetermined set of transaction 
rules and responsive to a transaction request by validating and accepting the transaction, 

a grants management system provided in communication with the transaction system 
and comprising: 

an interpretation logic unit to convert values of the transaction request from a domain 
of the transaction system to a domain defined for grant identified from the plurality of grants, 

a dimensional control unit to determine if the converted data maps to a classification 
that has been defined under the grant to be valid, 

an availability control unit to determine, based on a set of rules derived from 
administrative and financial requirements of the plurality of grants and encoded in a database, 
if the converted data would cause a limit defined under the grant to be exceeded, and 

a database storing converted transaction of the transaction requests that map to valid 
classifications that do not exceed the defined limits. 

7. The system of claim 6, wherein the database stores the converted transaction in the 
domain defined for the identified grant. 

8. The system of claim 6, further comprising: 

a reporting and billing manager to generate a report and/or a bill when the report is due 
according to a predetermined set of reporting and billing rules. 

9. The system of claim 8, wherein the reports and bills are generated in the domain 
defined for the identified grant. 

10. An enterprise management system for managing a plurality of grants for a recipient 
received from a plurality of grant sponsors, comprising: 

a transaction management system, operating under a predetermined set of transaction 
rules and responsive to a transaction request by validating and accepting the transaction, 

a grants management system provided in communication with the transaction system 
and responsive to the transaction request by: 
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converting values of the transaction request from a domain of the transaction system 
to a domain defined for grant identified from the plurality of grants, 

determining if the converted data maps to a classification that has been defined under 
the grant to be valid, 

if so, determining, based on a set of rules derived from administrative and financial 
requirements of the plurality of grants and encoded in a database, if the converted data causes 
a limit defined under the grant to be exceeded, and 

causing the transaction management system to reject to requested transaction if the 
limit is exceeded. 

11. The enterprise management system of claim 7, further comprising first and second 
databases, one provided for the transaction system and the other provided for the grants 
management system, each storing transaction data of transactions admitted by the grants 
management system, the transaction system's database storing the original transaction data 
and the grants management database storing the converted transaction data. 

12. The enterprise management system of claim 10, wherein the grants management 
system comprises a database storing a data cube of aggregated transaction data, the data cube 
having dimensions for all parameters defined for all grants managed by the grants management 
system. 

13. A computer-implemented method for managing a plurality of grants for a recipient 
received from a plurality of grant sponsors, comprising: 

receiving a transaction request and data associated with the transaction request from a 
transaction management system of a grant recipient; 

determining, based on a set of rules derived from administrative and financial 
requirements of the plurality of grants and encoded in a database, if the transaction request 
satisfies the rules imposed by the sponsor, and 

if so, admitting the transaction request: 

otherwise, rejecting the transaction request. 

14. The method of claim 13, further comprising converting the associated data to a 
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predetermined domain of a grant identified from the plurality of grants. 

15. The method of claim 13, further comprising determining if the associated data maps to a 
valid budget entry for the grant. 

16. The method of claim 15, further comprising rejecting the transaction request if the 
associated data maps to an invalid budget entry for the grant. 

17. The method of claim 13, further comprising determining if the associated data is 
consistent with a budgetary plan. 

18. The method of claim 17, further comprising rejecting the transaction request if the 
associated data is inconsistent with the budgetary plan. 

19. The method of claim 13, wherein the administrative and financial requirements from one 
sponsor is different from the administrative and financial requirements from another sponsor. 

20. A computer-implemented reporting and billing management method for managing a 
plurality of grants for a grantee received from a plurality of grant sponsors, comprising 

determining on a grants management system of the grantee if a report and/or a bill are 
due according to a predetermined set of reporting and billing rules imposed by a sponsor of a 
grant on the grantee; 

retrieving transactional data stored in the sponsor's terms from a transaction 
management system of the grantee; and 

if the report and/or the bill are determined to be due, generating the report and/or the 
bill in the sponsor's terms. 

21. The method of claim 20, wherein the report and the bill are generated according to the 
sponsor's currency, dimension, and fiscal year. 

22. The method of claim 20, further comprising using a blocking indicator to indicate 
whether a report and/or a bill are due. 
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23. An enterprise management system for managing a plurality of grants for a grantee 
received from a plurality of grant sponsors, comprising: 

a transaction management system, operating under a predetermined set of transaction 
rules imposed by a sponsor on the grantee and responsive to a transaction request by 
validating and accepting the transaction, and 

a grants management system of the grantee provided in communication with the 
transaction system, to determine if the transaction request satisfies the predetermined set of 
transaction rules imposed by the sponsor, and if so, storing transaction data, wherein the 
grants management system comprises: 

a reporting and billing manager to generate a report and/or a bill to the sponsor 
pursuant to a predetermined set of reporting and billing rules and the transaction data. 

24. The system of claim 23, wherein the sponsor and grantee run the grant on different 
terms. 

25. The system of claim 24, wherein, pursuant to a predetermined set of rules imposed by 
the sponsor, the reporting and billing manager retrieves the transactional data stored in the 
sponsor's terms, and generates a report and/or bill in the sponsor's terms when it is determined 
to be due. 

26. The system of claim 23, wherein the grants management system further comprises: 

an interpretation logic unit to convert values of the transaction request from a domain of 
the transaction system to a domain defined for an identified grant, 

a dimensional control unit to determine if the converted data maps to a classification 
that has been defined under the grant to be valid, 

an availability control unit to determine if the converted data would cause a limit defined 
under the grant to be exceeded, and 

a database storing converted transaction of transaction requests that map to valid 
classifications that do not exceed the defined limits. 
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27. An enterprise management system for managing grants for a grantee received from 
grant sponsors, comprising: 

a transaction management system operating under a predetermined set of transaction 
rules and responsive to a transaction request by validating and accepting the transaction, 

a grants management system provided in communication with a transaction system 
wherein the transaction system comprises: 

an interpretation logic unit to convert values of the transaction request from a domain 
of the transaction system to a domain defined for an identified grant, 

a dimensional control unit to determine if the converted data maps to a classification 
that has been defined under the grant to be valid, 

an availability control unit to determine, based on the predetermined set of transaction 
rules, if the converted data would cause a limit defined under the grant to be exceeded, 

a database storing converted transaction of transaction requests that map to valid 
classifications that do not exceed the defined limits, and 

a reporting and billing manager to submit a report and/or a bill according to a 

predetermined set of rules. 



NY01 1641577 



-20- 



EVIDENCE APPENDIX 

No evidence has been submitted pursuant to 37 C.F.R. §§ 1.130, 1.131, or 1.132. No 
other evidence has been entered by the Examiner or relied upon by Appellant in the appeal. 
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RELATED PROCEEDINGS APPENDIX 

As indicated above in this Appeal Brief, "[t]here are no other prior or pending appeals, 
interferences or judicial proceedings known by the undersigned, or believed by the undersigned 
to be known to Appellant or the assignee, SAP, 'which may be related to, directly affect or be 
directly affected by or have a bearing on the Board's decision in the pending appeal.'" As such, 
there no "decisions rendered by a court or the Board in any proceeding identified pursuant to 
[37 C.F.R. § 41.37(c)(l)(ii)]"to be submitted. 
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